Vibe Coding 四天后的随想
最近在 L 站薅到了不少 Claude 模型的额度，正好又在写 llm-hooks 这个全栈项目，索性就尝试一下用 Claude 模型来 Vibe Coding。
我 Vibe 了哪些代码？
llm-hooks 是个全栈项目，而且为了在使用 Docker 部署时能够持久化数据（因为一般的免费 Docker 容器无法配置硬盘进行数据持久化），我少有地在项目中使用了数据库。
由于对于后端及数据库相关的操作不了解，所以后端部分的代码基本都是自行实现的。
我对于前端比较熟悉，所以也趁此机会尝试使用 Claude Vibe Coding 前端部分。
使用的技术栈？
经过搜索，我得知 React + TailwindCSS 的组合对于 AI 比较友好，貌似是由于 TailwindCSS 可以将样式代码内联在 HTML 中，同时相对于直接写 CSS 更简短的缘故。
虽然我个人不太喜欢 TailwindCSS，但是反正是 AI 来写，我只提供需求和后续的少许纠正，也就无所谓了。
既然用了 React + TailwindCSS，干脆就上全套，把 zustand、radix-ui 等都一起上了。构建工具还是使用我比较熟悉的 Vite。（后续在查询时发现其实可以直接使用 shadcn-ui，省去自己调组件样式的麻烦）
Vibe Coding 的体验如何？
我一开始高估了目前模型的能力，直接把整个项目前端部分中需要的功能点列出，直接要求模型完成前端页面的框架，外加一个主要的功能点。
不过结果上不太好。
一方面是写出的东西和预期差别较大，需要很多调整，并且不提功能上的问题，实现的 UI 本身也有很多问题。比如可点击元素没有设置鼠标样式。
另一方面是让 AI 一次性编写太多代码难以 Review。加上我对于 React 生态的技术栈熟悉度不足，使得这个问题更加严重。
我最后是怎么 Vibe 的？
首先让 AI 搭建项目框架，即页面整体布局、主题切换、黑暗模式等，不进行实际功能的开发。
再将功能点进行拆分，对于相对较为简单的 tab，比如只具备展示功能的 tab 页，就直接给定需求进行开发；对于需要展示和数据更新的 tab 页，则将需求进行拆分，比如拆分为展示和更新两部分，在一次 Vibe 时专注于其一。
Vibe Coding 后的体会？
第一是对于在使用自己不熟悉的技术栈时，对于有一定复杂度的需求不要直接 Vibe，一定要做需求拆分。否则 Vibe 的结果难以维护。
第二是对于自己比较陌生的技术栈不要 Vibe，除非不考虑后续维护，可以通过 Vibe Coding 像玩老虎机一样看看能不能 Vibe 成功。
第三是 Vibe Coding 对于需求拆分的能力要求高。如果拆得细了就和平时正常写没有太大区别，不算 Vibe；如果拆得粗了，AI 又写不明白，往往得反复推翻重来。